PD ROM 1

home *** CD-ROM | disk | FTP | other *** search

/ PD ROM 1 / PD ROM Volume I - Macintosh Software from BMUG (1988).iso / Electronic Messages / USEnet Digests / USEnet Vol. 4 / USEnet 4.29 < prev next >

Wrap

Text File | 1988-04-08 | 27.8 KB | 702 lines | [TEXT/ttxt]

29-Feb-88 08:37:56-PST,29149;000000000000 Return-Path: <usenet-mac-request@RELAY.CS.NET> Received: from RELAY.CS.NET by SUMEX-AIM.Stanford.EDU with TCP; Mon, 29 Feb 88 08:37:12 PST Received: from relay2.cs.net by RELAY.CS.NET id ab18687; 29 Feb 88 10:44 EST Received: from relay.cs.net by RELAY.CS.NET id aa01115; 29 Feb 88 10:33 EST Received: from sdr.slb.com by RELAY.CS.NET id ab01083; 29 Feb 88 10:29 EST Date: Mon, 29 Feb 88 09:28 EDT From: Jeffrey Shulman <SHULMAN@sdr.slb.com> Subject: Usenet Mac Digest V4 #29 To: usenet-mac@RELAY.CS.NET, PIERCE%HDS@sdr.slb.com X-VMS-To: in%"usenet-mac@relay.cs.net",in%"PIERCE%HDS@SDR.SLB.COM" Date: Mon 29 Feb 88 09:28:41-EDT From: Jeff Shulman <SHULMAN@SDR> Subject: Usenet Mac Digest V4 #29 To: Usenet-List: ; Message-ID: <573143321.0.SHULMAN@SDR> Mail-System-Version: <VAX-MM(218)+TOPSLIB(129)@SDR> Usenet Mac Digest Friday, February 26, 1988 Volume 4 : Issue 29 Today's Topics: 3-D transformations on a MACII? Re: Software for the Mac -- recommendations wanted. Loud Mac II Fan-- Replaceable? Summer Workshops/Programs for High School Mac Plus Video Output Re: Ever heard of VideoTrax backup system? New SE fan & screen jitter? Re: LightSpeed C 2.15 putchar??? MultiFinder Info Again A Custom WDEF Re: MacInHebrew problem ---------------------------------------------------------------------- From: mfi@beach.cis.ufl.edu (Mark Interrante) Subject: 3-D transformations on a MACII? Date: 21 Feb 88 18:03:29 GMT Organization: UF CIS Department Does anyone know if there is a color board for the MACII that does 3-D transformations? -- Mark Interrante CIS Department University of Florida Internet: mfi@beach.cis.ufl.edu Gainesville, FL 32611 (904) 335-8051 ------------------------------ From: lonetto@phri.UUCP (Michael Lonetto) Subject: Re: Software for the Mac -- recommendations wanted. Date: 21 Feb 88 17:47:22 GMT Organization: Public Health Research Inst. (NY, NY) Someone mentioned MacCalc. I've been using MacCalc at home since it came out, and it really is a nice simple spreadsheet (which can generate nicer output than Excel) At work we have Excel, which is more difficult to use for simple spreadsheets, but has formula and command macros (very nice to have if you use them). It also has it's own graphing, but I find it easier (and nicer) to transfer data from either of these programs into Cricket Graph (MacCalc doesn't do graphs). This last method of working points out a difficulty with BOTH of these programs. Whenever possible I LIVE in multifinder, especially at home (Mac+, 2.5MB). MacCalc "has quit unexpectedly" whenever I start it under multifinder. Excel works fine at work (1MB Mac+), and 272K (the default partition size) is plenty of memory for small spreadsheets (even 4 or 5 of them). HOWEVER, when I tried it at home, it grabbed 750K !! Excel only seemed to know about the 272K it was set for. 500K went into Limbo!! Does anybody know of: 1) any update plans for either of these programs that will fix these problems OR 2) any other spreadsheet with FORMULA macros which works with multifinder OR 3) a good statistical analysis program that will work with either of these. I'd really like to buy Excel for home (Even if I wanted to pirate it, it's useless without the manuals) but it seems that something must be very wrong with the way it works under multifinder. This is not confidence inspiring. My two cents... -- Michael Lonetto UUCP:(allegra!phri!lonetto) Dept of Applied Genetics Public Health Research Institute, 455 1st Ave, NY, NY 10016 ------------------------------ From: jasst3@cisunx.UUCP (Jeffrey A. Sullivan) Subject: Loud Mac II Fan-- Replaceable? Date: 21 Feb 88 18:40:11 GMT Organization: Univ. of Pittsburgh, Comp & Info Sys I am the happy owner of a Mac II SYstem with the following gripe: MY internal fan seems much louder than friends' fans. IS there any way of replacig the fan? If so, how about part numbers, etc? I don't suppose this could be a warranty item? -- .......................................................................... Jeff Sullivan University of Pittsburgh jas@dsl.cadre.pittsburgh.edu Intelligent Systems Studies Program jasper@PittVMS (BITNET) Graduate Student ------------------------------ From: UD069225@NDSUVM1.BITNET (Eric H. Romo) Subject: Summer Workshops/Programs for High School Date: 21 Feb 88 09:06:04 GMT Organization: North Dakota Higher Education Computer Network, Fargo, ND I have a friend who is a french 17 yearold who is coming to the US this summer and he's asked me for suggestions for some computer-related workshops or programs that he could take part in. So I'm asking you netters out there on his behalf. He's an avid Macintosh user and Apple II user as well. It would be interesting if their were some oppurtunities for him in those areas although anything involved with computers and programming is what he's looking for. Please e-mail your responses to me and I'll pass them along to him. Thanks a bunch! -Eric. -- ___________________________________________________________ | Bitnet/Usenet |$0.00| | |_____| | Eric H. Romo | | UD069225@NDSUVM1.BITNET | | Chemistry Department | | Grand Forks, N.D. 58202 | |_________________________________________________________| ------------------------------ From: macak@lakesys.UUCP (Jim Macak) Subject: Mac Plus Video Output Date: 22 Feb 88 17:53:39 GMT Organization: Lake Systems - Milwaukee, WI I just got a call from a friend asking about Mac video output options. We are not talking Mac II here, but rather Mac Plus. He wants to produce a demo on a Mac and show it on a CRT, i.e. a television-like monitor. He would also be interested in doing a VCR recording of the demo. Is it possible to add a device to get NTSC output from a Mac Plus? I believe this is what would be needed, yes? If so, please give any info you have. What other options are there for video output from a Plus? I'm sure I've seen the answer to this somewhere in the past, but I don't recall where. And besides, I don't remember the answer because I was never in need of the info. Thanks for your help. Please e-mail replies and I will summarize if warranted. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Jim --> macak@lakesys.UUCP (Jim Macak) {Standard disclaimer, nothin' fancy!} -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- ------------------------------ From: Myron-Meier@cup.portal.com Subject: Re: Ever heard of VideoTrax backup system? Date: 22 Feb 88 00:05:18 GMT Organization: The Portal System (TM) I haven't had any experience with the VideoTrax system, but I did get a chance to talk to Alpha Micro at the MacWorld Expo last month. The VideoTrax system has been available for quite a while in the form of an IBM card, but they just recently announced their SCSI version (ie for the Mac). Here's some info off their infosheet that I picked up at the show: * Each block of data is copied several times to ensure data reliability. Says that the data on the VideoTrax system is even more reliable than on the hard drive you're backing up. [Sounds great!]. Average error rate for a hard disk is 1 bit in 10 to the -10. Average error rate on VideoTrax tape is 1 bit in 10 to the -11. * after back the tape can be verified to be restorable * can connect to any VCR, although the VideoTrax one is modified to automate some operations, ie. rewind, stop, play, etc... Works with all VHS, Beta, 8mm, and foreign VCRs * In 2-hour mode, VideoTrax can store up to 80MB on one standard video tape In 4-hour mode, VideoTrax can store up to 160MB on one tape! * Backs up a megabyte of data in 1.3 minutes. = 10MB in about 13 mins. * Backup in either Image mode (whole hard disk) or File-by-File. * No tape formatting is required * data can be broadcast The person I talked to in the booth told me that the Software was proprietory and you couldn't use another program (ie DiskFit), [Darn!!] although the prog looked pretty extensive, I really can't comment on how fast/reliable it was. Don't write that check just yet though, He said that it probably wouldn't be ready until April or so...sorry. Their address is: Alpha Micro 3501 Sunflower Ave. Santa Ana CA 92704 (714) 957-8500 ------------------------------ From: whiteheada@byuvax.bitnet Subject: New SE fan & screen jitter? Date: 19 Feb 88 17:18:53 GMT SE fan kits (Apple) I just had two SE's upgraded and they are great! The fan noise is not even noticeable and the screen jitter is gone. The kit has a fan and a new vertical video card (installs on the end of the CRT). I highly recommend getting this upgrade. -- Armand Whitehead BYU ------------------------------ From: clive@drutx.ATT.COM (Clive Steward) Subject: Re: LightSpeed C 2.15 putchar??? Date: 23 Feb 88 00:58:18 GMT Organization: resident visitor Well, I should have tried this one before posting. I wasn't accurate as to the real problem, and neither was Dave Platt coherent!dplatt, who sent unix-gruish mail on the subject. More on that at the end. The real difficulty, doped out in the library sources, is that the LSC library function Init_stdio () doesn't always get called automatically, as it's supposed to. For now (we can hope it'll be fixed in 3.0), it's sufficient to call Init_stdio () once yourself right at the beginning of your main () program. It will self-protect against being re-called later. The actual problem is that any variant which ends up internally calling fputc (), as putchar () does, will fail unless it's after something like printf (), which happens to actually force the initialization. The apparent problem is that the initial data for the _file[] array's stdout (_file[1]) is apparently now not correct. I don't have the source for the current (2.15) libraries, so can't see it there (in stddata_file.c), but did print out actual contents by copying the FILE structs into dummys before calling any print/put code. On stdin, the InUse bit is properly set; on stdout, it's not, though the other relevant info I checked seemed ok. Then when fputc checks for InUse as a file-active flag, it fails there, returning -1 (EOF) as it should. And thus never calls putch (), which would have done the Init_stdio () and fixed this. Please copy, Rich Siegal/ LightSpeed people. ------------------------------ From: raylau@dasys1.UUCP (Raymond Lau) Subject: MultiFinder Info Again Date: 23 Feb 88 03:34:04 GMT Organization: The Big Electric Cat I'm asked once for information regarding data structures used by MultiFinder - such as the ones which tell what applications are running, how much memory they're taking, etc.. I didn't expect to get an answer and I didn't. Now, I ask again - but for a wider group of people. Jasik Design's The Debugger is a lovely debugger. I prefer it over TMON and MacsBug.... It works great - until MultiFinder came along. When I inquired - When? I received the answer - Apple has not released enough information on MultiFinder. So I'm not the only ignorant one! Must we break out that copy of MacNosy that comes with the Debugger and start disassembling MF to figure out how it works? Is this information some big trade secret of Apple's? Inside Switcher was nice, now where's Inside MultiFinder? -- Raymond Lau GEnie: RayLau 100-04 70 Ave. CIS: 76174,2617 Forest Hills, NY 11375-5133 Delphi: RaymondLau United States of America MacNET: RayLau uucp: raylau@dasys1.UUCP (..{phri,cucard,bc-cis,mstan}!dasys1!raylau}) ------------------------------ From: ephraim@think.COM (ephraim vishniac) Subject: A Custom WDEF Date: 22 Feb 88 15:59:09 GMT Organization: Thinking Machines Corporation, Cambridge, MA Since mentioning in a comp.sys.mac article that I had seen a circular window on the Mac, several people have asked for source code or a copy of the program. Following is the help text from the program called "Windows Demo." The program features a variety of unusual window types, and the help text explains how they are produced. I will send the actual program (and this text) to info-mac, so that internet users can retrieve it from sumex. Even though it was compiled long ago with Megamax C, the program now runs on a Mac II - I just patched all those nasty 02B6's to 0A78's and there's no problem any more. ---------------------- Start of Help Text ------------------------- Program by Richard Koch Department of Mathematics University of Oregon Eugene, Oregon 97403 The Macintosh toolbox contains routines which move windows, resize them, and so forth. These routines are quite complicated; when a window is moved, the system must erase the old version of the window, draw the window in its new position, draw newly exposed portions of other windows, and recalculate the visible portions of all windows. It is natural to suppose that the toolbox routines which do these things assume that windows are rectangular, but in fact the routines have been written to handle windows of any shape whatever. Most Macintosh programmers use one of the six predefined windows at the left; these windows are basically rectangular (the final window has curved corners). But it is easy to define other window shapes. Windows can have holes in the middle, curved borders, fancy frames, and other unusual features. Some Macintosh users believe that the computer keeps a complete copy of each window in memory even when the window is not visible on the screen. But that is not correct. The Macintosh knows how to draw window frames and redraws portions of these frames when they become visible. But the contents of windows are the responsibility of programs; the Macintosh issues a warning when a previously hidden portion of a window becomes visible, and the program does whatever it wishes. The program you are running is lazy and erases windows entirely when new portions become visible; by turning this feature off, you can see that the toolbox erases each newly visible portion of a window before reporting that it should be redrawn. Since round windows require extensive calculations, they slow the system down enough to let us see the window moving algorithms in operation. If a window is moved from one portion of the screen to another, the toolbox directly moves screen memory and no redrawing is necessary. It is easier for the toolbox to make this pixel move when the window moves up than when the window moves down. If a window is moved part way off the screen and later moved back on, the toolbox copies those portions still on the screen by a direct memory move, but remaining portions of the window frame and contents must be redrawn. To produce an unusual window, it is only necessary to write one function of the form long MyWindow(varCode, theWindow, message, param) int varCode, message; WindowPtr theWindow; long param; This function is called by the toolbox when the toolbox needs to know the shape of the entire window or its content region, when it needs to know where the mouse went down in the window, or when it needs to draw the window frame. All other Macintosh window operations are handled automatically without help from the programmer. The parameter "message" explains what operation to perform, and the parameter "param" contains additional information for some requests. It is possible to create several related windows with only minor variations in appearance; the parameter varCode explains which variant to use. This parameter must be between 0 and 15. The code for "MyWindow" can be put in the main program code area, or it can be placed in a resource of type WDEF. In the program you are running, code for the rectangular and square windows is included with other program code, but code for the round windows is in a WDEF resource with ID #128. The Macintosh system contains two WDEF resources with ID's 0 and 1 which define all of the standard windows on the left. The first five windows are defined in WDEF #0 using varCodes 0 through 5. The final window is defined in WDEF #1 using varCode 0. When the Macintosh is running a program and needs a resource, it first searches the program file for the resource and only searches the system file if the resource cannot be found in the program file. Consequently, it is possible to trick programs so they will produce round windows rather than rectangular windows. Using ReEdit, cut the entire WDEF resource from the program you are running and paste it into MacWrite. Then change its resource ID # from 128 to 0. When you run the resulting MacWrite, it will use round windows for all operations. (Warning: Text written into MacWrite will disappear under the frame of the round window, and the "OK" box for some dialogs will be hidden beyond the window frame. Often a dialog will accept "RETURN" as the equivalent of clicking on "OK," but otherwise you will be stuck and have to reset the computer.) The round window WDEF can be pasted into the FINDER itself, yielding a round directory. It is easy to use the round window from this program in your own programs. Simply copy WDEF #128 into your resources and change its ID number as appropriate. Your resource code should also contain a window definition somewhat like TYPE WIND ,128 ; window resource ID First Round Window ; window title 40 80 120 300 ; top left bottom right Visible NoGoAway ; window status 2048 ; WindProcID (see below) 0 ; RefCon The actual program code will create this window in the usual way using a line like wp = GetNewWindow(128, wStorage, -1L); Of course this last line will be different if you are using another language, but everything else will be the same. The only strange feature here is the rule for assigning the WindProcID number. This number should equal sixteen times the WDEF resource number of the appropriate window definition code plus the varCode of the window variant. For example, the first five windows pictured at the left are produced by WDEF #0 in the system file with varCodes 0 through 5, so their WindProcID's are 0 through 5. The sixth window to the left is produced by WDEF #1 in the system file using varCode 0, so its WindProcID is 16. The WDEF for round windows allows sixteen possible variants. The rightmost bit in the variant number is 1 if the window has a title and 0 otherwise. The next bit left is 1 if the window has no grow box and 0 otherwise. The next bit is 1 if the window has a fancy woven frame and 0 otherwise. The final left bit is 1 if the title appears on the top and 0 if it appears on the bottom. So the variant number for a window with a title, grow box, fancy frame, and title at the top is 1 + 2*0 + 4*1 + 8*1 = 13. If you want to change the appearance of the round windows from this program, you will have to rewrite the code for "MyWindow." Below is this code, written using Megamax C. -- #include <qd.h> #include <qdvars.h> #include <win.h> #include <menu.h> #include <event.h> #include <dialog.h> pascal long MyWindow(varCode,theWindow,message,param) int varCode, message; WindowPeek theWindow; long param; { typedef Rect *RPtr; Rect r, rclose[4], rgrow, rtitle; int i,j,k; Point p; GrafPtr temp; PenState pnState; RgnHandle hstructure, hcontent, frame, htitle; Pattern pat; char title[256]; GetPort(&temp); SetPort((GrafPtr)theWindow); r = (*((GrafPtr)theWindow)).portRect; i = r.a.right - r.a.left; j = r.a.bottom - r.a.top; if (i > j) i = j; r.a.left = 0; r.a.top = 0; LocalToGlobal(&(r.a)); SetPort(temp); r.a.bottom = r.a.top + i; r.a.right = r.a.left + i; SetRect(&rclose[0],r.a.left + 3,r.a.top + i/2 - 6, r.a.left + 14,r.a.top + i/2 + 5); SetRect(&rclose[1],r.a.right - 14,r.a.top + i/2 -6, r.a.right -3,r.a.top + i/2 + 5); SetRect(&rclose[2],r.a.left + i/2 - 6,r.a.top + 3, r.a.left + i/2 + 5,r.a.top + 14); SetRect(&rclose[3],r.a.left + i/2 - 6,r.a.bottom -14, r.a.left + i/2 + 5,r.a.bottom -3); rgrow.a.right = r.a.left + i/2 + ((i/2)*10)/14; rgrow.a.bottom = r.a.top + i/2 + ((i/2)*10)/14; rgrow.a.left = rgrow.a.right - (9*141)/100; rgrow.a.top = rgrow.a.bottom - (9*141)/100; for (k = 0; k < 256; k++) title[k] = *(*((*theWindow).titleHandle) + k);ptocstr(&title); j = StringWidth(&title) / 2 + 15; rtitle.a.left = r.a.left + i/2 - j; rtitle.a.right = rtitle.a.left + j + j; if (varCode & 0x0008) { rtitle.a.top = r.a.top; rtitle.a.bottom = r.a.top + 16;} else {rtitle.a.bottom = r.a.bottom; rtitle.a.top = r.a.bottom - 16;} p.a.v = HiWord(param); p.a.h = LoWord(param); hstructure = (*theWindow).strucRgn; hcontent = (*theWindow).contRgn; switch(message) {case 0: if ((*theWindow).visible) { if (param == 0L) { GetPenState(&pnState); PenSize(18,18);PenMode(patBic); FrameOval(&r); SetPenState(&pnState); if (((*theWindow).hilited) && (varCode & 0x0004)) { pat[0] = 0xF8; pat[1] = 0x74; pat[2] = 0x22; pat[3] = 0x47; pat[4] = 0x8F; pat[5] = 0x17; pat[6] = 0x22; pat[7] = 0x71; FrameOval(&r);InsetRect(&r,1,1); FrameOval(&r);InsetRect(&r,1,1); frame = NewRgn();OpenRgn(); FrameOval(&r);InsetRect(&r,13,13); FrameOval(&r);CloseRgn(frame); FillRgn(frame,&pat);DisposeRgn(frame); FrameOval(&r);InsetRect(&r,1,1); FrameOval(&r); } else { FrameOval(&r);InsetRect(&r,3,3); if ((*theWindow).hilited) for (i = 0; i < 6; i++) { FrameOval(&r);InsetRect(&r,2,2);} else InsetRect(&r,12,12); InsetRect(&r,1,1);FrameOval(&r); } if (((*theWindow).hilited) && ((*theWindow).goAwayFlag)) { for (i = 0; i < 4; i++) { EraseRect(&rclose[i]); FrameRect(&rclose[i]);} } if (((*theWindow).hilited) && ((varCode & 0x0002) == 0)){ EraseRect(&rgrow); FrameRect(&rgrow);} if (varCode & 0x0001) { EraseRect(&rtitle);FrameRect(&rtitle); if ((*theWindow).hilited) { InsetRect(&rtitle,1,1); FrameRect(&rtitle); InsetRect(&rtitle,-1,-1); MoveTo(rtitle.a.left + 15, rtitle.a.top + 13); DrawString(&title); } } } else if (param == 4L) { GetPenState(&pnState); PenMode(patXor); for (i = 0; i < 4; i++) if ((i == 2) && (varCode & 1) && (varCode & 8)); else if ((i == 3) && (varCode & 1) && !(varCode & 8)); else { MoveTo(rclose[i].a.left+2, rclose[i].a.top+2); Line(6,6); MoveTo(rclose[i].a.left+2, rclose[i].a.bottom-3); Line(6,-6); MoveTo(rclose[i].a.left+1, rclose[i].a.top + 5); Line(8,0); MoveTo(rclose[i].a.left+5, rclose[i].a.top+1); Line(0,8); InsetRect(&rclose[i],4,4); EraseRect(&rclose[i]); } SetPenState(&pnState); } } return(0L); break; case 1: if (PtInRgn(&p,hcontent)) return(1L); else if ((PtInRect(&p,&rclose[0])) && ((*theWindow).goAwayFlag) && ((*theWindow).hilited)) return(4L); else if ((PtInRect(&p,&rclose[1])) && ((*theWindow).goAwayFlag) && ((*theWindow).hilited)) return(4L); else if ((PtInRect(&p,&rclose[2])) && ((*theWindow).goAwayFlag) && ((*theWindow).hilited) && (!((varCode & 1) && (varCode & 8)))) return(4L); else if ((PtInRect(&p,&rclose[3])) && ((*theWindow).goAwayFlag) && (!((varCode & 1) && !(varCode & 8))) && ((*theWindow).hilited)) return(4L); else if ((PtInRect(&p,&rgrow)) && ((varCode & 0x0002) == 0) && ((*theWindow).hilited)) return(3L); else if (PtInRgn(&p, hstructure)) return(2L); else return(0L); break; case 2: SetEmptyRgn(hstructure); OpenRgn(); FrameOval(&r); CloseRgn(hstructure); if (varCode & 0x0001) { htitle = NewRgn(); RectRgn(htitle, &rtitle); UnionRgn(hstructure, htitle, hstructure); DisposeRgn(htitle); } InsetRect(&r,18,18); SetEmptyRgn(hcontent); OpenRgn(); FrameOval(&r); CloseRgn(hcontent); break; case 3: return(0L); break; case 4: return(0L); break; case 5: r = *(RPtr)param; i = r.a.right - r.a.left; j = r.a.bottom - r.a.top; if (i > j) i = j; r.a.right = r.a.left + i; r.a.bottom = r.a.top + i; FrameOval(&r); return(0L); break; case 6: return(0L); break; } } ---------------------- End of Help Text --------------------------------- Ephraim Vishniac ephraim@think.com Thinking Machines Corporation / 245 First Street / Cambridge, MA 02142-1214 ------------------------------ From: leonardr@uxe.cso.uiuc.edu Subject: Re: MacInHebrew problem Date: 21 Feb 88 08:27:00 GMT According to the programmer, when last I spoke with him, there was a definate problem using MacinHebrew with the new ADB keyboards. It had to do with the way he was handling the keymapping. He recommends (as do I) that you acquire a copy of the Hebrew Interface System from a local dealer (or from Apple since your dealer amy not have it). and work with that instead since it is guarenteed to work and it comes with Laser Fonts as well. -- +---------------------------------+-----------------------------------+ + + Any thing I say may be taken as + + Leonard Rosenthol + fact, then again you might decide+ + President, LazerWare, inc. + that it really isn't, so you + + + never know, do you?? + + leonardr@uxe.cso.uiuc.edu + + + GEnie: MACgician + + + Delphi: MACgician + + + + + +---------------------------------+-----------------------------------+ ------------------------------ End of Usenet Mac Digest ************************ -------